SuperHack/SuperHack CD.bin/Hack/MISC/HTC31.ZIP/HOWTO3_1.TXT

Text File | 1996-05-18 | 5.7 KB | 114 lines

            HOW TO CRACK, A TUTORIAL - LESSON 3 (1)
                 by +ORC (the old red cracker)

How to crack, an approach                         LESSON 1
How to crack, tools and tricks of the trade       LESSON 2
-> How to crack, hands onn, paper protections     LESSON 3 (1/2)
How to crack, hands on, time limits               LESSON 4
How to crack, hands on, disk-CDrom access         LESSON 5
How to crack, funny tricks                        LESSON 6 (1/2)
How to crack, intuition and luck                  LESSON 7
How to crack windows, an approach                 LESSON 8
How to crack windows, tools of the trade          LESSON 9
How to crack, advanced cracking                   LESSON A (1/2)
How to crack, zen-cracking                        LESSON B
How to crack, cracking as an art                  LESSON C
How to crack                                      INDEX

LESSON 3 (1)
HOW TO CRACK, HANDS ON - Password protected programs

SOME PROBLEMS WITH INTEL's INT
The INT instruction is the source of a great deal of the
flexibility in the PC architecture, because the ability to get
and set interrupt vectors means that system services (included
DOS itself) are infinitely extensible, replaceable and
MONITORABLE. Yet the Int instruction is also remarkably
inflexible in two key ways:
-    an interrupt handler DOES NOT KNOW which interrupt number
     invoked it.
-    the int instruction itself expects an IMMEDIATE operand:
     you cannot write MOV AX,x21, and then INT AX; you must
     write INT x21.
That would be very good indeed for us cracker... unfortunately
many high level language compilers compile interrupts into PUSHF
and FAR CALL instruction sequences, rather than do an actual INT.
Another method is to PUSH the address of the handler on the stack
and do RETF to it.
     Some protection schemes attempt to disguise interrupt calls,
this is particularly frequent in the disk access protection
schemes (-> see LESSON 5) that utilize INT_13 (the "disk"
interrupt).
     If you are attempting to crack such programs, the usual
course of action is to search for occurrences of "CD13", which
is machine language for interrupt 13. One way or another, the
protection scheme will have to use this interrupt to check for
the special sectors of the disk. If you examine a cross section
of the program, however, you 'll find programs which do not have
"CD13" in their machine code, but which clearly are checking the
key disk for weird sectors. How comez?
     There are several techniques which can be used to camouflage
the protection scheme from our nice prying eyes. I'll describe
here the three such techniques that are more frequent:
1)   The following section of code is equivalent to issuing an
INT 13 command to read one sector from drive A, side 0, track
29h, sector ffh, and then checking for a status code of 10h:
     cs:1000   MOV  AH,02     ;read operation
     cs:1002   MOV  AL,01     ;1 sector to read
     cs:1004   MOV  CH,29     ;track 29h
     cs:1006   MOV  CL,FF     ;sector ffh
     cs:1008   MOV  DX,0000   ;side 0, drive A
     cs:100B   XOR  BX,BX     ;move 0...
     cs:100D   MOV  DS,BX     ;...to DS register
     cs:100F   PUSHF          ;pusha flags
     cs:1010   PUSH CS        ;pusha CX
     cs:1011   CALL 1100      ;push address for next
                              instruction onto stack and branch
     cs:1014   COMP AH,10     ;check CRC error
     cs:1017   ... rest of verification code
     ...
     ...
     cs:1100   PUSHF          ;pusha flags
     cs:1101   MOV  BX,004C   ;address of INT_13 vector
     cs:1104   PUSH [BX+02]   ;push CS of INT_13 routine
     cs:1107   PUSH [BX]      ;push IP of INT_13 routine
     cs:1109   IRET           ;pop IP,CS and flags
Notice that there is no INT 13 command in the source code, so if
you had simply used a debugger to search for "CD13" in the
machine code, you would never have found the protection routine.

2)   Another technique is to put in a substitute interrupt
instruction, such as INT 10, which looks harmless enough, and
have the program change the "10" to "13 (and then back to "10")
on the fly. A search for "CD13" would turn up nothing.

3)   The best camouflage method for interrupts I have ever
cracked (albeit not on a INT 13) was a jump to a section of the
PROGRAM code that reproduces in extenso the interrupt code. This
elegant (if a little overbloated) disguise mocks every call to
the replicated interrupt.
Bear all this in mind learning the following cracks.

CRACKING PASSWORD PROTECTED PROGRAMS
     Refer to lesson one in order to understand why we are using
games instead of commercial applications as learn material: they
offer the same protection used by the more "serious" applications
(or BBS & servers) although inside files that are small enough
to be cracked without loosing too much time.
     A whole series of programs employ copy protection schemes
based upon the possess of the original manual or instructions.
That's obviously not a very big protection -per se- coz everybody
nowadays has access to a photocopier, but it's bothering enough
to motivate our cracks and -besides- you'll find the same schemes
lurking in many other password protected programs.
     Usually, at the beginning of the program, a "nag screen"
requires a word that the user can find somewhere inside the
original manual, something like: "please type in the first word
of line 3 of point 3.3.2". Often, in order to avoid mistakes, the
program indicates the first letter of the password... the user
must therefore only fill the remaining letters.

Some examples, some cracks: